Software network functions (NFs) are software applications that process packets in a network traffic stream. Examples of such NFs include network intrusion detection systems (IDS), protocol or WAN optimizers, firewalls, Network Address Translators (NATs), and so forth.
In some instances, network traffic is partitioned across multiple instances of a single NF. Running multiple instances of an NF is sometimes necessary when a total incoming traffic load exceeds the processing capability of a single NF instance. In such scenarios, a mechanism is often used to partition or “load balance” incoming traffic across the NF instances. Such load-balancing is often used in network configurations where network traffic is processed by a single NF, or by a sequence of NFs (the latter is commonly referred to as a “chain,” or “network service function chain” of NFs).
Typically, such load-balancing should preserve “correctness” of network traffic. That is, each incoming packet should typically be directed to the particular NF instance that holds state needed to process that packet. In some scenarios, correctness should be maintained even as the number of NF instances varies dynamically and for NFs that modify a packet's headers and/or payload.
The problem of partitioning an incoming traffic stream across multiple instances of an NF arises in the context of many scalable software services; e.g., web services. A typical approach in many such contexts is to insert a standalone load-balancer on the path between incoming traffic and the NFs. This load-balancer may be implemented as a standalone appliance, a standalone software virtual machine or container, or a standalone software service. Approaches based on a standalone load-balancer may be well suited to software services that act at the application layer such as web services, storage services, etc. However, these approaches often fail to meet goals such as correctness, scalability, efficiency, low performance overhead, and automation within an NF context. This is because NFs are typically deployed as a “bump in the wire” between two communicating endpoints and/or may modify packet headers and/or payloads of network traffic traversing the NFs.